(This blog post is a more firm version of a series of tweets and forum posts I made a few weeks ago. This should also be considered a refresh of this post by Mirco Bauer a few years ago) It has been said that Mono is bloated, and that people should use lighter frameworks that don t pull in hundreds of meg . How much basis in reality is there for those comments? Well, let s do a little thought exercise. How much space is the minimum space needed for several languages to work? For this experiment, we will be looking at the required installation size on disk of several language frameworks, each time installing the bare minimum for a command-line hello world app in that language to run. For example, the Ruby result is the minimum install required to run:

puts 'Hello world'

and the Mono result is the minimum install required to run the following code, which has been compiled on a different machine using dmcs :

public class Hello1
 
   public static void Main()
    
      System.Console.WriteLine("Hello, World!");
    
 

Obviously, for dynamic languages like Ruby and Python, there is no compiler step needed. For languages like C# and Java, it is fair to compile these on a different machine as end-users of packages running these frameworks receive binaries, not source they do not need a development environment. So, on to the test environment. This is a bare bootstrapped AMD64 Debian Unstable system, as of today (i.e. debootstrap sid /tmp/badger ). Its install size is 275MB. So how much space? Ruby 1.9 Test code is as follows:

puts 'Hello world'

Install requirements are as follows:

root@dream:/# aptitude install ruby1.9.1
The following NEW packages will be installed:
  libffi5 a  libruby1.9.1 a  libyaml-0-2 a  ruby1.9.1 
0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 4703 kB of archives. After unpacking 13.1 MB will be used.

OpenJDK 7 Test code is as follows:

class HelloWorldApp  
    public static void main(String[] args)  
        System.out.println("Hello world");
     
 

Install requirements are as follows:

root@dream:/# aptitude install openjdk-7-jre-headless
The following NEW packages will be installed:
  ca-certificates a  ca-certificates-java a  dbus a  fontconfig-config a  
  icedtea-7-jre-cacao a  icedtea-7-jre-jamvm a  java-common a  
  krb5-locales a  libavahi-client3 a  libavahi-common-data a  
  libavahi-common3 a  libcap2 a  libcups2 a  libdbus-1-3 a  libexpat1 a  
  libffi5 a  libfontconfig1 a  libfreetype6 a  libglib2.0-0 a  
  libglib2.0-data a  libgssapi-krb5-2 a  libjpeg8 a  libk5crypto3 a  
  libkeyutils1 a  libkrb5-3 a  libkrb5support0 a  liblcms2-2 a  libnspr4 a  
  libnss3 libnss3-1d a  libpcre3 a  libpcsclite1 a  libsystemd-login0 a  
  libxml2 a  openjdk-7-jre-headless openjdk-7-jre-lib a  openssl a  
  sgml-base a  shared-mime-info a  ttf-dejavu-core a  tzdata-java a  ucf a  
  xml-core a  
0 packages upgraded, 43 newly installed, 0 to remove and 0 not upgraded.
Need to get 51.5 MB of archives. After unpacking 137 MB will be used.

Python 3.2 Test code is as follows:

print ("Hello world")

Install requirements are as follows:

root@dream:/# aptitude install python3.2-minimal
The following NEW packages will be installed:
  file a  libexpat1 a  libffi5 a  libmagic1 a  mime-support a  python3.2 a  python3.2-minimal 
0 packages upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
Need to get 4853 kB of archives. After unpacking 17.7 MB will be used.

Mono 2.10 (C#) Test code is as follows:

public class Hello
 
   public static void Main()
    
      System.Console.WriteLine("Hello world");
    
 

Install requirements are as follows:

root@dream:/# aptitude install mono-runtime
The following NEW packages will be installed:
  binfmt-support a  cli-common a  libmono-corlib4.0-cil a  libmono-i18n-west4.0-cil a  libmono-i18n4.0-cil a  
  libmono-security4.0-cil a  libmono-system-configuration4.0-cil a  libmono-system-security4.0-cil a  
  libmono-system-xml4.0-cil a  libmono-system4.0-cil a  mono-4.0-gac a  mono-gac a  mono-runtime 
0 packages upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
Need to get 4383 kB of archives. After unpacking 11.5 MB will be used.

Of course, every time I try to make the argument that Mono is much leaner than what people propose as an alternative, the anti-Mono brigade go on the defensive and insist that nobody in their right minds uses Python or Ruby either everything ever should be written in Qt. So, hypothetically Qt 4.8 (C++) Test code is as follows:

#include <QTextStream>
int main(int argc, char **argv)
 
   QTextStream s(stdout);
   s << "Hello, world!\n";
   return 0;
 

Install requirements are as follows:

root@dream:/# aptitude install libqtcore4
The following NEW packages will be installed:
  libffi5 a  libglib2.0-0 a  libglib2.0-data a  libpcre3 a  libqtcore4 
  libxml2 a  sgml-base a  shared-mime-info a  xml-core a  
0 packages upgraded, 9 newly installed, 0 to remove and 0 not upgraded.
Need to get 10.3 MB of archives. After unpacking 27.8 MB will be used.

Presented without comment for your consideration. Edit: There are complaints that these numbers are misleading, because they show default package manager behaviour, rather than what happens when passing extra flags or config file settings to Apt. When disabling installation of Recommends: packages, the numbers change as follows:

• openjdk-7-jre-headless 137 MB -> 116 MB
• ruby1.9.1 13.1 MB -> 13.1 MB
• python3.2-minimal 17.7 MB -> 6.1 MB
• mono-runtime 11.5 MB -> 10.9 MB
• libqtcore4 27.8 MB -> 13.7 MB

In my last blog post about smartphones, I urged the universe at large to help maintain a variety of ecosystems, to help foster competition and originality amongst vendors and the same day I hit publish, WebOS was killed. Apparently the universe hates me. Since then, a few things have changed. My main phone since the day of its release was the HP Pre 3, running WebOS and whilst I still have a soft spot for the OS, the Pre 3 was simply too buggy for me to use full time. The main issue is that I use my phone as an MP3 player in the car but the Pre 3 would pause playback at the end of a track every half dozen tracks or so making it impossible to drive the 85 miles to work without needing to root around in the armrest and poke a touchscreen. Not something I really want to do whilst moving and ultimately too big a papercut to deal with. So, come the new year, I moved on to my next device, a Nokia N9 running MeeGo Harmattan. Ultimately, this was an even bigger failure for me than the Pre 3 was, and I lasted maybe two weeks with it before giving up and going back to the HP. Beyond massive usability errors in the software (especially the braindead unkillable pop-up demanding Internet access, even when none is available), the worst for me was how it handled the MP3 player task. My usual way of working is to have the phone hooked up to the stereo with a 3.5mm jack, and the car switches to headset Bluetooth profile to handle calls this is pretty common on cars too old to support A2DP profile (Stereo music-capable headphones). WebOS and Android are fine with this but not the N9. The N9, instead, will output all audio through the last connected audio device, regardless of how much that might not be helpful. Get in car, start music playing, plug in cable, start engine and it plays audio for about three seconds before the Bluetooth connects, and it switches to outputting music via the Headset bluetooth profile (not something that my car can do). Unplug and replug the cable, and music works but incoming calls are silent until I disconnect the 3.5mm jack, as it outputs the headset audio through the headphone socket. I just couldn t deal with this big a step back from WebOS as far as my workflow goes, and gave up. So, where next? Well, a funny thing happened a co-worker with generally very good instincts regarding consumer electronics usability told me that his housemate had just bought a Nokia Lumia 800 Windows phone (the WP7-based cousin to the N9) and loved it. Enough that said co-worker was considering getting one himself. This was a very strange thing to hear, especially from an iPhone owner, about a Microsoft product. I d been generally interested in WP7 on an academic level for a while, but to hear that degree of praise of the actual product was interesting. Also interesting, and roughly simultaneous, was seeing Sajid Anwar s reverse engineering of the proprietary Zune file transfer protocol go from theory into an actual set of libmtp patches. So if the capability to use Banshee to transfer music on is here or near and it can t be as braindead as Harmattan when it comes to headphone/bluetooth behaviour, then why not jump ship and squeeze a handset out of Orange? About a week after my co-worker replaced his iPhone with a Lumia 800, I bought one too. So where to begin? Well, I ll begin at the start: WP7 is a joy to use. It really just is. It s the first mobile OS to try something radically different in the UI department for years. Everyone else these days (especially Android) builds iPhone rip-offs to varying degrees, and even the iPhone interface has a lot in common with the old old OLD interfaces found on the dumb Nokia phones of the 1990s. WP7 has an interface which provides just the right level of passively visible information and interactivity, and manages to do it with an elegance that no Android home screen filled with widgets will ever manage. The uncluttered screens are easy to read, and the Metro usability paradigms are trivial to pick up and learn. Without a doubt I d recommend WP7 to friends and family from a usability perspective, and the Microsoft engineers and designers responsible for cooking up the WP7 interface are worthy of praise. And I m not the only one saying this Apple co-founder Steve Woz Wozniak recently came out with a similar line. That s the good. There s also some bad, make no mistake. I m going to cover all the reasons WP7 sucks over several paragraphs. But overall, a smartphone is a device which I expect to suck the question is how bad the suck is, and whether it gets in the way of me using the device for what I need at the time. Moreso than MeeGo, moreso than Android, and even WebOS (and I m still a big WebOS fan), WP7 has more good points than bad points. But there s still some room for improvement, and some room for caution and since I know there are a few Microsoft folks following me on Twitter, I m going to go over my prescription for continued platform success. Oh, one more thing before I start: I know WP7 isn t Free Software. As an end user, I really don t care about that. I just want something that works something I didn t get from WebOS and Harmattan, both of which are primarily Free Software stacks. I m not saying there s a causal relationship there, or that a mobile OS can t be both Free Software and good just that as an end user, my favourite platform right now is non-Free. Take from that whatever you like. It s also vitally important, as Free Software folks, never to lose sight of what the other players in the market are up to. If you can t objectively assess why people are using a proprietary option by using it & recognising its good points (i.e. what to steal & what to improve) then you can t hope to win over users. So. WP7 s downsides in detail. In-place updates. Seriously guys, even Apple can manage this now. Why can t Windows Phone? I understand that making backups is smart and all updates come with a mandatory backup but I really shouldn t be tied to a PC to update a post-PC device. Also, those backups are useless, since they cannot be restored onto replacement devices in the case of failure or theft, so fix that too. Update all the things. An iPhone sold in June 2009 still has access to the latest iOS releases. Android phones are notorious for shipping with an outdated version of the OS, then getting at most one major update over the phone s lifetime (usually the device is abandoned by its manufacturer within months of release). Which camp does Microsoft want to align with, there? Every Windows phone 7 device released should receive Windows Phone 8, even with some features disabled. Anything less is punishing every existing customer, in the hope that you ll attract new ones not a winning strategy for a fringe platform whose biggest evangelists are its users. Fix IMAP. IMAP isn t hard. Yet WP7 never seems to work properly with a subset of my mail, never showing the message body & just saying Downloading forever. Fix it. Bing sucks. Bing s search results are terrible. Either do something to make them bearable, or allow me to pick which search engine I get when I hit the search button. A Google live tile isn t the same thing. Make killing apps easier. I know you stole the WebOS card view for multitasking (hold the back button) please also steal the WebOS ability to close apps. I don t want to have to go into an app and bash back repeatedly until it quits. This is particularly annoying for Internet Explorer. Make reinstalling apps easier. If I want to install every app I previously had installed on a new device, without restoring a backup, this should be easy. There are third party apps which try to plug this gap. Find a way to support copyleft. I d like to port a few C# apps to WP7, but because they re LGPL, I can t. The code s copyright holders would have no issue with their code being on WP7, as long as end users have a mechanism to replace the libraries, so why not find a way to allow this? e.g. when compiling an app, let me mark a library as user-replaceable , then allow for some mechanism where an end user can replace those assemblies with their own version. Let me use multiple Google calendars. WP7 only lets me add/see appointments on my default Google calendar. I want to add/see things on my wife s calendar, which is shared with me. WebOS can do this. MTP-Z is the devil. I do not need or want encrypted end to end communication between my PC and my camera device, to transfer a photo off. I do not need or want encrypted end to end communication between my PC and my MP3 player to transfer a photo on. Let s be honest, the only reason for MTP-Z is to enforce DRM on Zune-rented music tracks and honestly, there s no good reason to require MTP-Z for *all* communications if all you want to do is protect one folder or file extension. Now, since MTP-Z theoretically forces me to use Zune for many tasks better handled by other apps, now I get to write multiple criticisms of Zune s desktop app and as long as MTP-Z is enforced, every Zune failing is a Windows Phone failing too. Zune: Support Windows codec infrastructure, and transcode where needed. Windows Media Player can play Ogg Vorbis files. No, not out of the box, but if one installs the required codecs. Zune should support the same files as WMP if you want to ensure people don t try to copy files to a portable device which are not supported on that device, then you should have an API in place to allow for pluggable seamless transcoding of files as required Banshee allows me to do this (e.g. to copy files I have as .flac to devices which do not support it). Zune: Search my tracks, not the web. Zune s searching is terrible it doesn t do as-you-type searches, and when I hit enter, matches from my collection are given a tiny little space compared to matches from the Zune music store. Let me easily pick the track I feel like listening to, don t make it a chore Zune: Let s solve metadata together. I absolutely love how nicely the Zune app on desktop and on phone shifts as appropriate to the currently playing artist (e.g. changing the lock screen to an image of the artist in question). However, Zune doesn t make it obvious how to set an album s metadata to support this, and it s particularly frustrating when it s a minor difference of spelling causing a track not to get the nice treatment e.g. UNKLE versus U.N.K.L.E. . Either start making heavy use of audio fingerprinting services like MusicBrainz to fill in metadata, or allow me to search for fully supported artists when filling in track metadata Zune: Random playlists are useless on devices. I like smart playlists. In Banshee, I have one to pick 12GB of random tracks, which I can sync to my phone. I can t do this with Zune. If I try to just sync all my random music to my phone, it errors out due to lack of space. If I have a random playlist, the random selection changes multiple times during a sync resetting the sync, wiping out half the tracks that were transferred on, and starting again. As a result, the sync goes on for literally hours, never ending up with more than a gig or so of tracks on the phone. Random playlists should be freezable, so I can transfer them to my device in peace, then get a new random selection when I want. So, that s my list of miserable failure and it s still a less painful list than any other mobile OS I ve used. Perhaps one day Android will approach being usable, perhaps Blackberry s BBX will actually appeal to human beings rather than corporate IT managers, and perhaps Mozilla s delightfully named Boot to Gecko will get some traction. Who knows. All I know is, My Lumia 800 is the best phone I think I ve ever owned, and it s important for anyone working in the mobile space to understand why.

It s seeming increasingly likely that reports regarding the future of Banshee, Tomboy, and the rest of the Mono stack in the default Ubuntu desktop install are accurate. Ubuntu 12.04 will likely be the first Ubuntu release since 5.10 not to ship with any Mono apps in the default install ending a run of 12 releases over 6 years. The decision seems to have come about during the default apps session at the Ubuntu Developer Summit just ended in Orlando, Florida. Prior to heavy vandalism, the only reasons cited for the change in the UDS session log are Banshee not well maintained and porting music store to GTK3 is blocked on banshee ported to GTK3 . Other reasons mentioned but not in the session logs are complaints that it doesn t work on ARM. I m using a lot of conjecture in this first paragraph because the news about the decision appeared on the blogosphere before anywhere else. The first many Banshee or Tomboy developers read about it was reading a flurry of activity on the Tweetosphere from the anti-Mono activists declaring victory. So first, a word on the cited reasoning. Banshee works fine on ARM, since Mono works fine on ARM. Xamarin, the company behind most upstream Mono work, earns their income almost entirely from ARM versions of Mono, running on the varied ARM implementations found in smartphones. Every major Banshee release is personally tested on my Genesi EfikaMX, an ARM system with a Freescale i.mx51 processor. I ve also demonstrated Banshee running in an Ubuntu chroot on my HP Touchpad, an ARM-based tablet. What is known is that Banshee has some problems running on Texas Instruments OMAP4 processors the target ARM platform for Canonical s ARM work. None of the Banshee upstream developers, Mono upstream developers, or Mono Ubuntu team has ever been able to reproduce the cited problems, since problems specific to an exact ARM chip are impossible to reproduce without the requisite hardware and none of us owns an ARM system matching Canonical s target. That Banshee is still a GTK+2 app is true. A port to GTK+3 is almost complete, but blocking on a single technical bug deep within GTK# s guts, which could be fixed by someone with sufficient knowledge of GTK+ semantics. Nobody with the required GTK+ knowledge has stepped forward with a fix at this point in time. As for the final point, that Banshee is not well maintained, this seems like a directed personal insult against the active and responsive Banshee maintainer, Chow Loong Jin, and upstream bug triager David Nielsen, in addition to the immeasurable hours contributed free of charge for the benefit of Ubuntu users by various other members of related Mono app and library teams, including myself. I need to stress at this point that my annoyance with this decision has nothing to do with the actual app changes. Keeping Tomboy and gbrainy, at a cost of about 25 meg of unsquashed disk space, is a hard argument to make compared with those two plus Banshee for 40 meg. Dropping gbrainy and Tomboy, and switching to Rhythmbox, will save about 30 meg of unsquashed space, all told.I m unconvinced that Rhythmbox is a technically superior app to Banshee several features which were gained by the first app swap will be lost again but that s another long tedious argument to be had. No, what has me deeply angered is the shambolic way the changes were made and announced. Significant accommodations were made by Banshee upstream in order to make life easier for Canonical to integrate Banshee into their OS. For one thing, that s why the Ubuntu One Music Store support is a core Banshee feature, not part of the third-party community extensions package. If Banshee was being considered for replacement due to unresolved technical issues, then perhaps it would have been polite to, I don t know, inform upstream that it was on the cards? Or, if Canonical felt that problems specific to their own itches required scratching, then is it completely beyond the realm of possibility to imagine they might have spent developer resources on bug fixing their OS and sending those fixes upstream? Or even and call me crazy providing access for upstream to specialized hardware such as a $174 Pandaboard to empower upstream to isolate and fix unreproducible bugs specific to Canonical s target hardware? And here s where it gets more astonishing for me Canonical paid money to ship one of the community-based packagers responsible for the stack, Iain Lane, to Orlando for UDS, and didn t think it was worth bothering to perhaps inform him hey, the stuff you work on is in danger of being axed from the default install, maybe you should go to this session . So I m not cross that the stuff I work on has been removed from the default install. I intend to continue working on it as I have for the last 4 years, through my work in Debian. No, why I m cross that I heard about it from fucking Boycott Novell. Regardless of your opinions regarding Banshee or its stack, if you read the above and don t see it as an abysmal failure of community engagement by a company whose community manager wrote a book on the damn topic, then there s something seriously wrong with your understanding of how community labour should be seen as a resource. Maybe someone at Canonical should try reading Jono s book. It s not a first-time offence, and this mail from a PiTiVi developer regarding changes in 11.10 makes for useful further reading. [edit] There is some worthwhile discussion going on on the ubuntu-desktop mailing list covering the technical issues surrounding the decision, I would suggest it s a good place for ongoing technical discussion.

A very popular refrain on tech sites is that the high street cannot support multiple competing phone ecosystems. It s a reasonable position to take. Do phone stores want to train their employees on six or seven different OSes? Do consumers understand the differences, and should they need to? Do app developers want to rewrite their app six or seven times? The obvious answer to all of these is no . Stores only want to train their employees once, developers want to write their app once. Choice is bad, because choice is complicated. You can have it in any colour, so long as it s black. The problem is, we need those competing efforts, for the entire market to increase in quality. Until the iPhone appeared on the market, Google s nascent mobile phone OS looked more like a poor man s Blackberry OS than what ended up shipping on the HTC Dream and later devices. Windows Phone 7 didn t ship with any multitasking at all and now the Mango update will be incorporating a multitasking model largely thieved from WebOS. iOS only just got support for updating the phone s firmware without being plugged into a host PC via USB, something which a few Android devices and all WebOS devices have always supported. Consider, for comparison, the web browser market. It would be easiest if there was only one web browser but that browser would quickly stagnate and cause pain, the way Internet Explorer 6 did when it had almost the entire market. It wasn t until upstarts like Firefox and Opera and Chrome and more started showing off their unique ideas that the entire pack started improving including IE, with IE9 supporting most of the features that the competition introduced. Every smartphone shipping today has something to offer that other devices don t and every smartphone OS shipping today has something to offer that other OSes don t. iOS has the widest app catalog. Android is Open Source (FSVO Open ). WebOS has the best multitasking, and Just Type . Windows Phone 7 offers a drastic new user interface paradigm. Blackberry OS is built for messaging tasks, and has the best sysadmin control. Symbian is well, okay, sometimes there s a time to let go but the same applies for web browsers too. Smartphones are communication devices that people use every day of their lives, and every consumer has different needs we shouldn t try to push them into an ill-fitting category, just to satisfy ourselves that it s probably only possible for three mobile platforms to succeed in the mass-market . For some people, Blackberry OS really *is* the best choice, and no matter how much you pretend, an iPhone would enhance their lives. And as for the app question tough shit. Plenty of app developers only target iOS even though Android is overtaking in the market, and if they really want to reach as many people as possible, then use a cross-platform framework like PhoneGap or some of Xamarin s products. Single-ecosystem apps are a low-effort push to reach as many people possible with minimal investment, and the only way to satisfy that class of developer is to eliminate ALL competition in the marketplace iOS-only devs are this decade s IE6-only devs. Everyone is entitled to their opinion, but I for one am sick of all the tales of doom and gloom that immediately surround any effort which isn t iOS or pure Android. We have a marketplace of ideas, which we should be celebrating, and not dumping on. I m eagerly awaiting delivery of my HP Pre 3, with all the unique possibilities it offers me which simply another Android device wouldn t have. And the big difference between WebOS and Nokia s Maemo/MeeGo efforts, for those who are still doubtful, is HP haven t spent years trying to deliberately sabotage the platform. Give it time. If I m wrong, the worst-case scenario is being lumbered with an awesome phone.

Well hello there. A couple of days ago my debian.org account was created, meaning that I'm one1 of the crop of current new Debian Developers. Actually the news was broken to me by Rhonda when I attached to irssi after arriving at work, a nice surprise

<Rhonda> All congratulate Laney on becoming a Debian Developer.  ;)
* Rhonda . o O ( http://db.debian.org/search.cgi?dosearch=1&uid=laney )
<Laney> Rhonda: I did?!?!?!

I'll quickly introduce myself by paraphrasing from the background section of the AM report before letting you go about your business. I apparently submitted my first thrilling patch to the alsa-tools package in Ubuntu on February 2nd, 2008. This was sponsored into Hardy by Daniel Chen. Thereafter followed a myriad of exciting patches to various packages that somehow managed to convince a bunch of people that I had enough skill to become an Ubuntu developer. Fast forward a while and I get sucked into the world of Debian packaging by the CLI/Mono strike force of Mirco Bauer and Jo Shields by way of the Mono 2.0 transition. This was where I got my first Debian upload, and it was in this team that I fully realised both the excellence and importance of Debian in the FOSS world2. At some point the Debian Haskell Group formed and I've been involved to some extent there all along too. What I've mainly learned from these two groups is that team maintenance is a really great way to look after a bunch of related packages. When I see people touting new packages about, I often recommend that they look at the list of teams to find a nice home. Perhaps one or two actually did. Thanks to everyone who's supported me so far. I hope to be able to do the same for others in the future.

Last night I wanted to buy an album on Amazon and I couldn't do the checkout as the site required me to install the Amazon MP3 Downloader to make the purchase and download of the album. The downloader is not needed for a single song though, but buying each song separately would be more expensive and more work. The good news is that it automatically offered me packages for different Linux distros: Ubuntu, Debian, Fedora and OpenSUSE instead of telling me off for using Linux and leaving me behind with a Windows only download. But here comes the catch, all offered packages are only for the Intel 32-bit architecture. Now this is a showstopper for me, as I am running an AMD64 Debian which is a 64-bit architecture. I first tried to download and run the 32-bit debian package nonetheless as there was some hope with the ia32-libs and ia32-libs-gtk package. But this was not working as the application needs gtkmm libraries like libglademm and bailed when I tried to run it. So I filed a wishlist bug report against ia32-libs-gtk for inclusion of gtkmm and possibly other needed libraries to run the Amazon MP3 downloader on AMD64. So I bought the album using MusicLoad instead which simply puts all songs in a single archive on-the-fly and let me download that archive. When I tweeted my frustration on Twitter I was hinted by Jo Shields and also by Gabriel Burt that there would have been a much simpler solution to this issue by using Banshee which includes an Amazon MP3 Store plugin: This plugin allows you to log into your Amazon account browse their store like the regular Amazon store, plays the song samples directly, purchase songs, downloads the songs and imports them into Banshee's database so you can play them right away. And as if this wasn't good enough yet, with the the purchase of MP3 songs on Amazon using Banshee automatically makes a donation to the GNOME foundation. As I am the only one who forgot or wasn't aware of this awesome solution this deserved some blogging. Update: some people pointed out that clamz is also available to make MP3 purchases on Amazon.

Most probably haven't noticed yet but I finished the Mono 2.10.1 debian packaging effort of the past 3 months and uploaded it to Debian/Experimental. With Mono 2.10 I had to make the biggest changes in Mono packaging since the big Mono 2.0 upload. The runtime no longer supports the 1.0 and 2.0 runtime profile, instead it now supports the 2.0 and 4.0 runtime profile. This meant I had to drop all libmono*1.0-cil packages and add libmono*4.0-cil packages. This sounds like a lot of s/1.0/4.0/ work but it actually wasn't. Mono 2.10 ships a lot of new libraries over 2.6 and I had again to decide where they should go. "Where should this $library go?" I have been playing this game for the past 7 years maintaining Mono and I finally gave up on it... What, where, when, why? I could give now a 2 hours talk of the issues behind the current packaging approach (keeping the number of library packages low) but instead I will do something else. Please, just take a look at this picture for a second: If your browser crashed, your eyes hurt or your brain simply melted, I think you have got the idea. The Big Split The cure? cli-common-dev! This is a package that contains 2 extremely important debhelper packaging tools for packaging Mono/CLI related packages called dh_makeclilibs and dh_clideps. If you don't know these, they do exact the same thing as dh_makeshlibs and dh_shlibdeps do. dh_makeclilibs generates library dependency tracking information and dh_clideps consumes that information to automatically generate the package dependencies for you. So each library of the 4.0 runtime profile has now it's own package, simple as that, the rest does cli-common-dev for me and you. "Hey, that Mono packaging bastard is polluting the Debian archive because of his laziness!" No, I am not. This packaging change not only has the advantage of simplifying the packaging and with that bringing new Mono versions faster to you but also reduces the typical install size for applications as they will only pull in the really used libraries of Mono instead of groups of them. I don't have any numbers handy right now as none of the applications are built against Mono 2.10 (yet), but when the transition starts we will get numbers. New Features There is also a new SGen flavor of Mono available called mono-runtime-sgen which is no longer using the conservative non-generational Boehm's garbage collector but SGen which is a simple generational garbage collector with promising advantages. And here some more Mono 2.8/2.10 news from /usr/share/doc/mono-runtime/NEWS.Debian.gz:

• SGen Precise Stack Scanning
• Enhanced SIMD with new methods for Vector data type conversions and swapping elements in vectors
• ASP.NET MVC 3.0 (not included, only supported)
• The C# Interactive Shell can now be used as shebang: #!/usr/bin/csharp
• .NET 4.0 runtime
• C# 4.0 compiler
• ASP.NET 4.0
• Managed Extensibility Framework (MEF)
• System.Data.Services.Client (OData)
• glib was replaced with eglib
• Removed .NET 1.1 runtime

Architecture Regressions With the initial upload of Mono 2.10.1 to Debian/Experimental the architecture world broke apart and it regressed on all Mono architectures except for i386 and amd64 There is a reason it's called experimental isn't there? In mono 2.10.1-3 I could solve all regressions except for kfreebsd-* and armel. Jo Shields fixed the remaining regressions and the world started to look good again in mono 2.10.1-4! He also took care of mono-basic, mod-mono and xsp, but mod-mono and xsp are still waiting for the translation call deadline to pass by so they can also be uploaded to Debian/Experimental. Planned Transition As mentioned above, there will be a Mono 2.10 transition needed when the packages hit Debian/Unstable. There is no ETA yet on this when it will happen as I have to coordinate this with debian-release first. But as things are not showtime ready in experimental anyhow, this will not happen too soonish. The Mono 2.10 transition plan will be covered in a following post. GIVMENOWPLX OMG, all this rumbling about Mono 2.10 and I still haven't said a word on how to obtain it, sorry about this, just do this and I will shut up now:

echo "deb http://ftp.debian.org/debian experimental main" >> /etc/apt/sources.list
apt-get update
apt-get install -t experimental mono-complete

(this is the easiest way of getting only mono 2.10.1 from experimental)

Yes, it's that time of the year: I am blogging. I was using Jaws as my blogging tool and CMS for the past few years more or less and I am finally switching to something new. I was running a SVN snapshot of Jaws and haven't updated nor maintained that one for about 3 years. This reduced my abilility to blog a lot as I had to look after bugs and jumping through the hoops to make a post. At some point I wanted to replace Jaws with something better that fits my needs but didn't find anything. I have been keeping an eye on Joey Hess' ikiwiki for quite some time, but never felt the desire to blog something important and thus postponed solving my website mess. For those who don't know ikiwiki yet, it is a wiki compiler based on a version control system like git which generates the website when you push your commits to the git repository. The wiki uses the markdown syntax but also supports other engines. ikiwiki is written in Perl which is not my favourite language, but I have seen worse. When I wrote the Debian packaging tools for the Common Language Infrastructure, which are based on debhelper, I had to study code written by Joey Hess. Putting the syntax aside (I mean it's Perl, it can't be beautiful because of that) he does well designed and implemented software and this is the reason ikiwiki is a great candidate despite the used language. Jo Shields suggested dogfeeding myself with a .NET based blog, but ASP.NET is just junk, but with Manos de Mono I am actually considering it! Manos is written in beautiful C# without any ASP.NET close to it, but is extremely new and has no blogging or wiki engine written for it yet. I was involved in Jaws's development and I didn't want to run into the same issue again for now (more hacking the tools, less using them). So last night I finally made the decision, installed ikiwiki and made my first post with it, yay! The markdown syntax feels very naturaly to me. I usually end up searching for the syntax documentation every 2nd paragraph, but not on this one...

Hear me ramble about Mono on This Week In Debian for a half-hour! Go on, hear me! [MP3][Ogg]

If you ve ever gotten tired of waiting for a new Mono release to appear, and taken matters into your own hands by compiling your own copy of Mono, you ve likely faced the problem of missing libraries. That s weird, it says it can t find gtk-sharp, but I have that package! This happens because every version of Mono on your system has what s called a Global Assembly Cache a location where all system-wide assemblies lives. So when you run an app like Tomboy, it loads its libraries such as GTK# from the GAC belonging to the Mono runtime being used. Ordinarily, this is in /usr/lib/mono/gac on a Debian/Ubuntu system. When you have your parallel Mono, it doesn t share a GAC as a result, libraries in your main distro GAC are not available in your DIY GAC, as they were never registered in there. Typically, the advice is to either start compiling every lib you need into a non-standard place too however, here s a better idea. Why not make Apt take care of not only your system s GAC but additional GACs too? We actually have structures in place to handle this, so it s not as hard as you think (merely relatively unknown). This guide does NOT take startup scripts into account it s your problem to ensure you re using the correct mono command to run your copy of MonoDevelop or Tomboy or whatever. You should probably learn about update-alternatives and $PATH for this. Oh, and this guide will BREAK HORRIBLY if you try to uninstall system mono completely. Don t try it. Setup step 1: preparation Don t install parallel Mono into /usr/local. I don t care what happens to you if you do. Use some random folder in /opt, usually a per-build prefix like /opt/mono-2.10 Setup step 2: duplicating existing magic Open a terminal, and copy /usr/share/cli-common/runtimes.d/mono to a new filename, e.g. /usr/share/cli-common/runtimes.d/mono-2.10 Setup step 3: tweak duplicate magic Open your copied file in an editor, and change the name value on line 27ish (e.g. from Mono\n to Mono (parallel 2.10 install)\n ). Then change the two places in the file, on lines 64ish and 120ish, from /usr/bin/gacutil to /opt/mono-2.8.2/bin/gacutil or equivalent. Setup step 4: apply magic to existing packages Run /usr/share/cli-common/gac-install mono-2.10 (or whatever filename you picked for your runtimes.d entry) as root. This will instantiate your parallel GAC(s). From now on, every GAC library you install or uninstall will happen to every single runtime in runtimes.d. To go back to how things were before, with only a single Mono runtime: Uninstall step 1: empty out parallel GAC Run /usr/share/cli-common/gac-remove mono-2.10 (or whatever filename you picked for your runtimes.d entry) as root. This will remove all packaged entried from your parallel GAC(s). Uninstall step 2: remove magic Delete your file from runtimes.d

[ If you haven't heard of this debate yet, you probably want to read Vincent Untz's and Mark Shuttleworth's blog posts. ] Last year, I gave a talk at FOSDEM about Debian and Ubuntu (slides of a slightly updated version). One of my points was that Debian has better values, being a volunteer-driven project where decisions are taken in the open. In contrast, Ubuntu is a project managed and controlled by Canonical, and recent history has shown that Canonical had no problem imposing some decisions to the developers community: first with the inclusion of UbuntuOne, then the switch from Google to Yahoo! to Google as the default search engine, both to increase revenue streams. So one should not be surprised by the Banshee story. I find Mark s justification quite difficult to buy, and similar to Apple s model where 30% of the revenues from the App Store go to Apple, and 70% to the seller of the application. For those wondering how much work was done by Canonical directly on the Banshee package: the banshee package in Ubuntu natty is based on the package currently in Debian experimental. The package is mainly maintained in Debian by an Ubuntu developer not paid by Canonical AFAIK, Chow Loong Jin. There are some differences between the Debian package and the Ubuntu package, which are fairly limited (full diff here) and mainly about enabling UbuntuOne and disabling the other music stores. That patch itself apparently was provided by Jo Shields, who doesn t seem to be a canonical employee. (Feel free to correct me) I think that one of the conclusions to draw from this story is that we now have several proofs that Ubuntu isn t a volunteer-driven project, and that volunteer contributors should really decide whether they are OK with working for free for Canonical, or if their free time would be better spent on other projects where they actually have a chance to influence decisions. From the Debian POV, I m still convinced that we should take the feedback that we receive from Ubuntu in consideration to improve our Debian packages (by looking at patches made by Ubuntu, or at bugs reported in Launchpad). But my motivation for contributing to Ubuntu directly has just diminished a bit more (not that it was very high before).

Not for the first time, I ve seen the suggestion in the echo chamber that Mono packages should be moved from Debian into the non-free repository, which is not formally part of Debian. The reason, as it so often is, is patents specifically this time, the searing risk posed to Debian and its users that Mono s packaging does not (and technically could not without forking from upstream) provide base class libraries which implement only the content of ECMA-335 4th Edition. As I understand it, this implies three things about the suggestion/demand: firstly, that the individual in question believes that Mono end users are at risk from patent litigation from Microsoft Corp because Mono s implementation of Microsoft.NET beyond the content of ECMA 334/335 infringes on Microsoft patents; secondly, that the Microsoft Community Promise which promises not to assert legal claims over third party implementations of ECMA-335 4th Edition (and ECMA-334 4th Edition which defines the C# language) would render a pure ECMA-only runtime safe if it existed (which it does not); thirdly that without the protection offered by the Microsoft Community Promise, the source code licenses of Mono are irrelevant the patent risk renders the software non-Free. It appears, unfortunately, that the community of Free Software Advocates don t actually understand what Free Software actually IS. That explains an awful lot, but should surprise nobody. So here s a lesson on what, exactly, is being advocated for. The Free Software Foundation defines four Software Freedoms these are the minimum criteria required for something to be considered Free Software by the FSF:

• The freedom to run the program, for any purpose (freedom 0).
• The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help your neighbor (freedom 2).
• The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

Other groups have their own variants on these, but those are really just clarifications on the FSF definition - for example, the Debian Free Software Guidelines mostly line up, but have some additional clauses such as clause 4 which allows software to be considered Free if source code may be redistributed without modifications, as long as patches may be shipped alongside. These four freedoms are offered to you by the software s copyright holders only, and apply regardless of their choice of license any Free license, from a lengthy legal tome like the MPL to the completely-Free WTFPL, will offer you these four basic freedoms as a minimum, and any additional clauses in their licenses cannot seek to restrict these freedoms. These four freedoms represent the beginning, and end, of whether a piece of software is Free or not. Software does not need to be developed in the open, in a community-responsive way, in order to qualify as Free projects such as Google s Android, which are developed under a throw a final release over the wall, bugs and all, and expect people to thank you for it model, are still free, even if contribution is difficult. Actually, on a related note, software does not need to solicit upstream contribution of any kind in order to qualify as Free as long as you personally can redistribute the code with changes, then that s enough. Software does not need to serve a fully or even partially legal purpose in order to qualify as Free the favoured tool for causing distributed denial of service attacks, Low Orbit Ion Cannon, is Free Software, even though realistically it serves no legal purpose. DeCSS, the code initially used to allow DVD media to play on Linux (by breaking the CSS encryption mechanism) is Free Software. Software does not need to be useful or tasteful in order to qualify as Free the Last Measure Operating System, a minimalist OS primarily designed to loudly display the famous shock site images from goatse and related, is Free Software. Even in somewhat less clear-cut cases of taste, your personal opinion of software has no bearing on whether it is Free Software, as long as the four freedoms are guaranteed by the author(s). Software does not need to have only Free dependencies to qualify as Free Software it is entirely permissible to write software which relies upon a non-Free framework or library, and release your code under a Free license. It is the downstream recipient s problem to provide the dependencies, including their choice to craft a Free replacement for any non-Free code you make use of. Debian has a special repository called contrib, where Free software which only works with non-Free data, lives for example, Free game engines which require the insertion of proprietary game data in order to operate. You could write Free addons for expensive proprietary software such as Matlab, and as long as your code is Free, your responsibilities are met. Software does not need to avoid patents software, algorithmic, or otherwise in order to qualify as Free. The Freetype font library was still entirely Free Software when Apple were slinging threats around regarding font hinting data. FFmpeg, the Swiss Army knife of media codec libraries, is Free Software regardless of the number of codec patents it breaks. Software does not need any third party approval to be Free Software the rights of Free Software can only be offered by the copyright holders, and the opinion of third parties is an irrelevance as to whether software is Free. The GPL d clone of Blizzard Entertainment s Battle.net servers, bnetd, is Free Software, regardless of legal takedown notices. Third parties cannot influence whether or not a piece of software is Free. They can influence tangentially related topics, such as whether the software can be legally used, but that s the limit. And even within a given piece of software, where copyright is shared by contributors, the author of one component has no say on other components. And you can t make code which is already released as Free, suddenly un-Free you can, if you hold all the copyrights, close up future versions, but your existing code remains Free forever. Reasonably, you can opt to avoid using a piece of software because you have requirements beyond it merely being Free Software Cdrtools has been avoided in Debian for a long time due to the upstream author s legal threats and rambling but that is a side issue as to the question of whether or not the software is Free. Patents are simply not involved in the question of whether or not something is Free Software, except for one narrow case: where Free Software is released by somebody who also holds related patents, and uses a license such as Ms-PL or Apache 2.0 or GPLv3 which requires them to also release those patents to those using/distributing the software. Outside that narrow situation, patents do not relate to the question of whether something is Free Software even if a company releases some source code under a license like BSD then demands patent fees from end users. So, on to the original topic of Mono. Every piece of Mono s source code is released by its authors under a license which guarantees the FSF s Four Freedoms. Whether or not you find Mono useful or tasteful does not affect that Free status. Whether or not Mono infringes upon any laws or patents does not affect that Free status. That Mono contains some libraries whose upstream author is Microsoft does not give Microsoft even the remotest claim to a single line of code outside the code they wrote and even then, it wouldn t be an issue, since the licenses they use are Free. In fact, both the licenses used in the Microsoft portions of the source base make patent grants to all users, in addition to guaranteeing the FSF s Four Freedoms and any license contamination would decrease, not increase, any risk of legal attack from Microsoft. There s even plenty of Microsoft code available for re-use at a lower level than the currently re-used libraries: The Microsoft.NET Micro Framework (for use on embedded platforms direct to the metal) is under the Free Software Apache 2.0 license, and would provide access to some of Microsoft s runtime and class library code, complete with a patent grant, if it were desired. Please try to keep your thought processes straight. If you want to argue that you re all for Free Software, please remember that there s plenty of Free Software you might not approve of and don t claim to be a Free Software advocate then use bogus arguments to claim that Free Software is not Free. Free Software includes LMOS and LOIC and Mono, whether you like it or not.

I ve never quit a job before. Well, not a real job. Quitting PC World was more than easy, it was practically required for my soul not to leave my body. Quitting Waitrose was, well, it was a freaking supermarket job. And Southampton football stadium I just stopped turning up after one girl fainted in the kitchen from heat exhaustion. But a real, proper handing in of notice is something new in no small part because I ve been in the same place since my first job as a new graduate. Not that I m ungrateful, mind. Looking after big iron at the University of Oxford has been pretty awesome more blinky lights than you can shake a stick at but there comes a time when you need to think about your career, and move on to pastures new. I m fairly sure six and a bit years is WELL past that point. When I started looking at work, I had only a few mandatory criteria a sysadmin job, working with Free Software, without any significant decrease to my monthly income. Beyond that well, in this economy, who am I to argue? What I hadn t accounted for, however, was a job whose awesomeness can t be contained. A job with a dedicated Free Software company whose entire staff roster, top to bottom, is filled with the most talented, smart, and generally awesome people you could hope to work with. Such a job would be a fevered dream, the mere ramblings of a madman. Yet, somehow, for the second time running, I find myself in an enviable job, working exclusively on Free Software. Being able to show off root access to a box with 256 cores and a tibibyte of RAM is pretty cool. But you know what s even cooler? A job where I never need to worry about openSUSE 10.1 administration ever again. A job where several of my colleagues are fellow Debian Developers, with all the prestige and knowledge that comes with such a title. And somehow, by rolling proverbial twenties, I find myself in that position. I am very, VERY proud to say that from the start of January, I ll be joining Collabora Ltd as their new Systems Manager.

There are corners of the Internest where foolish people congregate, and invent stories. These foolish stories are then read as gospel by trusting people, and reposted, until the original made-up source is concealed from view. As an attempt to stem this flow of disinformation, here are some commonly held but incorrect beliefs about the Mono framework, and an explanation of the reality of the situation, as far as I understand it. The next Mono version is co-developed with Microsoft There is a grain of truth behind this one, but it s a gross mischaracterisation. Mono 2.8, when it ships, will bundle, for convenience, a number of Free Software libraries, which are released by Microsoft under a license considered Free Software by the Free Software Foundation, the Ms-PL. These are:

• System.Web.Mvc and System.Web.Mvc2: ASP.NET MVC, a library for writing ASP.NET web pages with a model-view-controller design, similar to Rails for Ruby. This is not news System.Web.Mvc has been bundled in Mono since Mono 2.4.2 (June 25th 2009). System.Web.Mvc2 has been bundled in Mono since Mono 2.6.7 (July 14th 2010).
• System.Numerics: Mono re-uses Microsoft s implementation of BigInteger.cs from the Dynamic Language Runtime (see below). This is indeed new to Mono 2.8, as it is part of .NET 4.0 (Mono 2.8 targets .NET 4.0 compatibility by default).
• System.Data.Services.Client: The OData SDK client library. This is indeed new to Mono 2.8.
• System.ComponentModel.Composition: The Managed Extensibility Framework, a library for writing and using plugins. This is similar in scope to the existing Mono.Addins project. This is indeed new to Mono 2.8, although it was added to Mono Trunk in 2009.
• System.Web.Extensions: Microsoft Ajax, a library for using Ajax inside ASP.NET projects. This is not news MicrosoftAjaxLibrary has been bundled in Mono since Mono 1.2.6 (11th December 2007).
• Microsoft.Scripting.Core and Microsoft.Dynamic: The Dynamic Language Runtime is a framework permitting implementation of dynamic languages (such as Python or Ruby) on top of the core .NET runtime. It is used for IronPython and IronRuby, amongst others. The DLR has very recently changed license from Ms-PL to Apache 2.0, but the version bundled in Mono is still under the older license. This is not news the DLR has been bundled in Mono since Mono 2.6 (14th December 2009).

So, to summarise, there are five Free Software libraries written by Microsoft under the Ms-PL included in Mono 2.8 but only two of those five are new, and none of them were co-developed in any meaningful sense. Mono development is dead There have been reports that Mono development has ended, on the basis that no commits have been made to Novell s Subversion server for a few weeks. However, these reports miss one minor detail Mono has moved to Github.com. There were 35 commits from 9 different people to the main mono.git repository (of dozens of repositories under the main Mono project) in the last 2 days, at time of writing far from dead. Mono lacks features found in Microsoft.NET Mono lacks libraries found in Microsoft.NET, such as the Windows Presentation Framework GUI toolkit. In terms of features, i.e. things implemented at a compiler or runtime level, Mono is typically more advanced. This is helped in no small part by Mono s Free Software development model, allowing experimentation and what if changes to the core runtime which a sluggish corporate behemoth like Microsoft cannot accommodate. To give three real-world examples, Mono allows embedding of its compiler as a service, and provides a REPL shell this is a planned feature for .NET 5.0, but has been available for years in Mono; Mono.Simd provides a number of data structures which will run on any version of Mono or Microsoft.NET, but will use optimized CPU extensions like SSE when run on a sufficiently new version of Mono, on an appropriate architecture as far as I m aware, there is nothing like this available or planned for Microsoft.NET. Mono is able to produce fully compiled, static executables which do not need to JIT anything at runtime this is used for iPhone compilation, for example, where JITters are not permitted. There is no comparable feature in Microsoft.NET. Clearly, Microsoft.NET can only be thought of as more featureful if one defines features in terms of does it have lots of libraries? in terms of functionality, Mono is ahead. Mono can sneak onto your system without your knowledge If you don t have the mono-runtime package installed, you can t run Mono apps. It is possible to install some Mono apps alongside the awful-yet-popular mononono equivs package, since the popular equivs script fails to place Conflicts on the correct packages (F-Spot will be blocked, Tomboy will not). No package in Debian or Ubuntu embeds its own copy of the Mono runtime, and we have no plans to make any changes to packaging which would allow execution of any C# application without mono-runtime installed. If one is using a different OS, then things may be different e.g. The Sims 3 for Mac & PC uses embedded Mono, which you wouldn t know about without looking. Canonical are pursuing a pro-Mono agenda, and are responsible for it being pushed in Debian Mono development has been happening in Debian for longer than Canonical has existed the first upload was made in April 2002. Ubuntu is made primarily from software already available in Debian deemed of sufficient quality, and when F-Spot and Tomboy became parts of the default Ubuntu desktop system in 2006, both pieces of software were already available in Debian and deemed of sufficient quality. Nobody working on Mono in Debian is paid by Canonical actually, that s not entirely true, three packages related to accessibility are officially maintained by someone who was hired by Canonical after doing the initial packaging work when he worked for Novell. But the Mono runtime itself, Canonical have no influence over its direction in Debian. As for a pro-Mono agenda , they ve always taken an extremely pragmatic approach to language choice, never showing any real preference for one language or another when it comes to app selection. They don t exhibit any overt anti-Mono policies, which is not the same thing. The names of people contributing to Mono in Debian are not secret check the pkg-mono team page on Alioth. The System.Windows.Forms namespace is protected by Microsoft patents The truth is, nobody knows for sure if SWF, or any other part of Mono, or any other framework such as Vala or Python, is covered by Microsoft patents. The way the US patent system is contrived, it is actively dangerous to check whether something contains any patents when you write it, as you are liable for triple damages should it later emerge that there WAS a patent, even if your searching missed the fact. You cannot patent an API or namespace only a specific implementation of a software concept, in those countries where software patents are permitted. There has never been any evidence shown that Mono s implementation of SWF, or indeed any part of Mono, infringes any Microsoft-held patents, because if that were the case, then the code would be rewritten to avoid the issue much like the approach taken by Linux kernel developers when a patent becomes apparent. The belief within the Mono community is that the core parts of Mono as defined in ECMA334/335 are safe (they are covered by the Microsoft Community Promise patent grant); any of the Ms-PL libraries mentioned above is definitely safe (Ms-PL includes an explicit patent grant); and the rest of the package is likely safe too (on the basis that it is a named component of the Open Innovation Network s list of protected software and on the basis that there s unlikely to be anything patentable in one of many implementations of basic ideas like database connectors). Nobody knows for sure, because that s how the system works. But, again, nobody knows for sure that Microsoft patents don t apply to other frameworks such as Python there is simply a belief and an assumption that they do not. MonoDevelop contributors removed GPL code from MonoDevelop, in an attack on the GPL This is somewhat disingenuous, given MonoDevelop is LGPL. The MonoDevelop team excised the remaining GPL code (and there wasn t much of it) in order to grant greater Freedom to developers. Previously, the entire MonoDevelop IDE was a GPL combination, meaning any add-ins for the IDE also needed to be GPL, regardless of developer choice. Now, any developer can write an add-in for MonoDevelop, using the license of their choice, whether another Free license like the Mozilla Public License, or a proprietary closed-source add-in. They are still welcome to produce GPL add-ins, if they want to, as well. Mono won t run random Microsoft.NET apps anyway, so isn t really cross-platform Actually, this one is often true. When developers write apps for Windows primarily, they rarely take the time to think is this the correct way to do it? and will often plough on with an assumption about the Windows way of doing things. It might be simple things like filesystem assumptions (assuming a case-insensitive filesystem, or assuming a backslash is used to separate directories, not a forward slash). It might be more involved, such as using P/Invokes into Windows-specific C libraries, when a more cross-platform alternative is possible. So, often, random applications for Microsoft.NET won t run on Mono. The reverse is also true F-Spot or GNOME Do are fairly heavily tied to Linux (or to UNIX-like OSes with X11, at any rate), through the libraries they invoke being fairly platform-specific. You can write platform-specific Java, with one quick piece of JNI, too. It should be noted, however, that Mono makes the chance of .NET applications being ported to Linux (and/or Mac) much more likely, since even in the worst case scenario, a company only needs to fix a portion of their source to make it cross-platform. The Mono team have a tool called MoMA, which will scan an application and its libraries, and give you detailed reports on the app s portability. This info is used at both ends by app vendors who want to become more portable, and by the Mono team who want to fill in the most frequently encountered blanks. And, it should be stressed, writing cross-platform apps is entirely possible if one desires it e.g. the IRC client Smuxi is pure cross-platform C#, and the executables compiled on Mono on Linux will run fine on Microsoft.NET on Windows. Portability in this direction is important too consider how many people have been introduced to Free Software thanks to availability of Free apps on Windows like OpenOffice.org, Firefox, Pidgin or GIMP. You can download Tomboy for Windows, and work is ongoing on fixing Banshee portability issues (which are mostly caused by gStreamer). Mono on Android is a terrible idea which will be super slow There are two efforts to enable developers to write Android applications with Mono a paid proprietary product from Novell called MonoDroid, and an untitled porting effort by big-name Android hacker Koushik Dutta. I have no insight into MonoDroid since it hasn t been released yet, but Koush did some benchmarks of his work which exhibited some remarkable figures compared to Dalvik (and even compared to Sun Java for ARM). Those numbers haven t been updated to reflect the Froyo Dalvik JITter, but Mono on Android is still very exciting from a performance perspective. Mono isn t really Free Software The source code is all available under Free Software licenses. So, um, yes it is. We don t need Mono because we have $LANG By the same logic, we don t need $LANG because we have Mono. By all means, use the language of your choice other developers will use the language of their choice too. If you want to use Vala or Python or Java, then by all means, go ahead. It doesn t mean there s no room for more languages, better suited to other usage patterns. Haskell is great for some types of development, so is Fortran, and so is C#. You might not need Mono because of $LANG, but there are others in the world with different needs. Mono apps are all slow, and crash your computer, and stuff No userland app can crash your Linux system, unless there s a bug in the kernel, or you have some severe problems with your hardware. If you ve ever observed a crash as a result of running a Mono app, then it s really coincidence that Mono is tickling whichever part of your system is busted. As for slow startup time may well be slower than for apps written in C or Vala. There s a delay due to the JITter needing to compile all the libraries used by the application (we may AOT the most common libraries in a future Mono package version, at upstream s recommendation). Once an app is running, it should be fast compared to a Python app, and memory-light compared to a Java app. The new garbage collector in Mono 2.8 should also offer significant improvements to performance, especially under heavy workloads. Ubuntu s default GTK+ themes require Mono This is my favourite recent nonsense to emerge from the Internest. There are reports mostly restricted to IRC and blog comments, that (paraphrasing here) removing Mono removes the Ubuntu themes . Here s the reality: in Ubuntu 10.04, a new visual style was implemented throughout the distro. As part of this, small icons (e.g. notification area icons) were set to be black-and-white by default, and colourised when attention is needed (e.g. the power-off icon turns red when a reboot is needed, the messaging indicator turns green when there s a new message). All of these new monochrome icons are in a package named ubuntu-mono . Removing the ubuntu-mono icon package will also remove the new Ubuntu GTK+ themes, in the light-themes package. So there s your explanation: the themes have a dependence on some monochrome icons, not on the Mono framework.

I ve just made a new release of my GRUB2 gfxmenu themes. This time, there s an Ubuntu Lucid theme. It looks like this: Download it from here as always.

I ve finished uploading the latest version of the cross-platform MonoDevelop IDE to Debian Experimental. MonoDevelop is a full-blown IDE for working on software written in C#, Visual Basic.NET, Python, Vala, Java (via IKVM.NET), C, C++, and Boo. It also integrates support for debugging (both of C-based apps via GDB, and Mono-based apps via MDB or the new Soft Debugger), GUI design of C# apps, version control via Subversion, database querying, unit testing, and more. Oh, and for good luck, I ve also uploaded it to badgerports.org (which should now display okay on smaller displays), for use with Ubuntu 10.04, where support for authoring with Moonlight is included. It ll be in the main Ubuntu 10.10 repository at some point in the future, also with Moonlight support. Enjoy.

In my last post, about GRUB2 theming, there were a few people who were unhappy at the perceived difficulty of creating GRUB2 themes, largely based on the lack of documentation. And to be honest, those people are right if the documentation were complete & correct when I started, then I wouldn t have ended up bumping into all the bugs I did. So, to help on that front and to help kick-start GRUB2 theming in general, I m announcing Larval. More GRUB2 themes means more awesome-looking systems in the wild. Hopefully the GRUB2 upstream will embrace it as a project to help raise the profile and potential of GRUB2. It didn t take me long to realise the most obvious way to develop such an editor: GRUB2 s canvas-based layout system has an awful lot in common with XAML, so the obvious choice was to develop using Silverlight (or, more specifically, Gtk.Moonlight). Larval s internal theme format is XAML files, which are then exported to (and imported from) GRUB2 s simple text based files. The biggest piece of work, to be honest, is the Managed implementation of a PF2 font reader/writer, so you can design a theme using the regular TrueType fonts of your choice, then have them automatically ported to PF2 format as required. I look forward to plenty of community input on Larval, once it reaches a point where I m sufficiently pleased with my (Ms-PL licensed) code to share it with the world. Until then, you ll have to make do with the above screenshot!

There s been a fair deal of talk on the intertubes lately about prettifying the boot process. The first I saw was a post from Lasse Havelund regarding a proposal for Ubuntu Lucid, and the second was regarding a forked version of GRUB2 called BURG, which adds some theming abilities. A tiny bit of research revealed that despite the existence of BURG, the regular upstream GRUB2 project already has graphical theme support, courtesy of a Google Summer of Code project by Colin Bennett (albeit with a few less features at time of writing). Since Lasse had gone to the hard work of actual design, I decided to try my hand at chopping his design up into a usable GRUB2 theme, and the result can be seen here. I ended up speaking with the upstream GRUB2 team (which has certainly lead to a strange alliance in one case) about Colin s GSOC themes, and as it turns out, the main reason there s no theme supplied with GRUB2 is that Colin s themes use non-Free elements (proprietary fonts like Helvetica are used heavily). Since I had learnt the theme format to a basic degree in doing my Ubuntu theme, I proposed making a genuinely Free theme starting with a Debian theme, and moving on to a generic GRUB2 theme afterwards. As I went along, I found a handful of bugs and feature oddities, which have almost all been fixed with incredible turnaround by Vladimir Serbinenko, the current maintainer of the gfxmenu code (there remain some questions regarding RTL support in themes, and how to gracefully deal with different aspect ratios) and I want to extend my thanks to him for his help. However, at this point in time, I m pleased to announce a theme I d consider ready for public consumption. It s obviously not perfect, and it uses the old visual style from Debian Lenny, but it s a fully Free starting point, which hopefully can be deconstructed by others seeking to make their own themes. It ought to scale fully to any 4:3 resolution. And it may explode and eat your disk on any version of GRUB2 Experimental other than r1499. Generally, the README is a good starting point. Oh yes, an URL. Try http://retro.apebox.org/grubthemes/ I ve been speaking with some folks on deviantART regarding using their Debian-themed wallpaper in future releases of my themes package, but for now, this should be enough for gfxmenu to get a little more exposure and a little more testing. And, hopefully, shift artist focus back from the theme-incompatible BURG fork to the real GRUB2 project.